Detection of infected network devices and fast-flux networks by tracking URL and DNS resolution changes

ABSTRACT

A system and method for detecting Fast-Flux malware are presented. Domain name system (DNS) lookup requests to DNS servers from a local area network (LAN) to a wide area network (WAN) are monitored. The DNS lookup requests comprise requests to resolve uniform resource locators (URLs) to network addresses. The network addresses (IP) received from the DNS servers for the DNS lookup requests are monitored provide a URL-to-IP associations list. The DNS servers used for the DNS lookup requests for the URLs are monitored to provide a DNS Domain-to-DNS server associations list. A suspicious URL log based on the URL-to-IP associations list, and a suspicious DNS log based on the DNS Domain-to-DNS server associations list are generated.

FIELD

Embodiments of the present disclosure relate generally to detection ofthreats in network devices. More particularly, embodiments of thepresent disclosure relate to detecting Advanced Persistent Threats.

BACKGROUND

On a company network where there may be valuable assets to be protected,many techniques and software and hardware solutions are employed toprevent the loss of those valuable assets, but the current solutionshave proven ineffective at stopping the infiltration and exfiltrationattempts of intellectual property and data. One technique used byattacking hackers, commonly referred to as Advanced Persistent Threats(hereafter referred to as “APT” or “APTs”), is to infect a targetmachine by some mechanism to install malware to perform actions onbehalf of the attacking hacker. The APT will then begin to “call out” or“beacon” to a host or list of hosts on the internet on a recurringbasis.

A purpose of these callouts is to get through firewalls (which tend toprevent much incoming traffic but allow most outgoing traffic) and allowthe attacker to instruct or control the victim device to carry outactions such as surveying other systems, collecting data from theinfected system, further infiltrating the network, and sendinginformation back to the attacker. Attackers have over time evolvedbetter techniques for performing this call-back so that it is moredifficult to catch where infected hosts may be attempting to connect to.

One of the most advanced current techniques uses techniques referred toas “Fast-Flux” network systems for avoiding detections. Existing systemsdo not effectively identify Uniform Resource Locators (URLs) thatfrequently change Internet Protocol (IP) addresses or changingauthoritative Domain Name System (DNS) servers. The existing systemsgenerally use pre-defined lists of known suspicious URLs, IPs or DomainName System to perform detections.

SUMMARY

A system and methods for detecting Fast-Flux malware are presented.Domain name system (DNS) lookup requests to DNS servers from a localarea network (LAN) to a wide area network (WAN) are monitored. The DNSlookup requests comprise requests to resolve uniform resource locators(URLs) to network addresses. The network addresses received from the DNSservers for the DNS lookup requests are monitored to provide a URL-to-IPassociations list. The authoritative DNS servers used for the DNS lookuprequests for the URLs are monitored to provide a DNS Domain-to-DNSserver associations list. A suspicious URL log based on the URL-to-IPassociations list and a suspicious DNS log based on the DNSDomain-to-DNS server associations list are generated.

In this manner, embodiments of the disclosure use only algorithms todetermine suspicious behaviors which allows for previously unknowinglybad URLs, internet protocol addresses (IPs), or DNS servers to beidentified. Embodiments address a gap in current security monitoring andanalysis systems and aims to identify Single-Flux and Double-Fluxnetworks of the Fast-Flux network with a purpose of identifyinginternally infected network devices, which is a task that is not beingperformed by any service and system today. Embodiments of the disclosuredetect APT computer malware by examining and tracking URL-to-IPresolution requests as well as the authoritative DNS servers which areproviding the URL resolutions.

There may be expected to be many DNS servers in a DNS resolution chainwhich may be used, and many may not be known (e.g., as they maygenerally not be provided in a URL resolution response), but ones ofinterest are the authoritative DNS servers. By looking for changes inpairings, URL-to-IP and DNS Domain-to-DNS server embodiments identifythe URLs and DNS servers most likely involved in a Fast-Flux malwarenetwork. Filters and control parameters are applied to thisidentification process to limit a number of false positive detections,and detected cases are used to identify network devices that may havebeen compromised.

In an embodiment, a method for detecting Fast-Flux malware monitorsdomain name system (DNS) lookup requests to DNS servers from a localarea network (LAN) to a wide area network (WAN). The DNS lookup requestscomprise requests to resolve uniform resource locators (URLs) toreceived network addresses (IP). The method further monitors thereceived network addresses (IP) received for the URLs from the DNSservers for the DNS lookup requests to provide a URL-to-IP associationslist, and monitors the DNS servers used for the DNS lookup requests forthe URLs to provide a DNS Domain-to-DNS server associations list. Themethod further generates a suspicious URL log based on the URL-to-IPassociations list and a suspicious DNS log based on the DNSDomain-to-DNS server associations list.

In another embodiment, a system for detecting Fast-Flux malwarecomprises a network traffic monitor and a malware detector. The networktraffic monitor monitors domain name server (DNS) lookup requests to DNSservers from a local area network (LAN) to a wide area network (WAN).The DNS lookup requests comprise requests to resolve uniform resourcelocators (URLs) to received network addresses (IP). The network trafficmonitor further monitors the received network addresses (IP) receivedfrom the DNS servers for the DNS lookup requests to provide a URL-to-IPassociations list, and monitors the DNS servers used for the DNS lookuprequests for the URLs to provide a DNS Domain-to-DNS server associationslist. The malware detector generates a suspicious URL log based on theURL-to-IP associations list and a suspicious DNS log based on the DNSDomain-to-DNS server associations list. The malware detector alsoindicates a presence of a malware program in the LAN based on thesuspicious URL log and the suspicious DNS log.

In a further embodiment, a non-transitory computer readable storagemedium comprising computer-executable instructions for detectingFast-Flux malware. The computer-executable instructions monitor domainname server (DNS) lookup requests to DNS servers from a local areanetwork (LAN) to a wide area network (WAN). The DNS lookup requestscomprise requests to resolve uniform resource locators (URL)s toreceived network addresses (IP). The computer-executable instructionsfurther monitor the received network addresses (IP) received from theDNS servers for the DNS lookup requests to provide a URL-to-IPassociations list. The computer-executable instructions further monitorthe DNS servers used for the DNS lookup requests for the URLs to providea DNS Domain-to-DNS server associations list. The computer-executableinstructions further generate a suspicious URL log based on theURL-to-IP associations list and a suspicious DNS log based on the DNSDomain-to-DNS server associations list.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF DRAWINGS

A more complete understanding of embodiments of the present disclosuremay be derived by referring to the detailed description and claims whenconsidered in conjunction with the following figures, wherein likereference numbers refer to similar elements throughout the figures. Thefigures are provided to facilitate understanding of the disclosurewithout limiting the breadth, scope, scale, or applicability of thedisclosure. The drawings are not necessarily made to scale.

FIG. 1 is an illustration of an exemplary flowchart showing a Fast-Fluxmalware detection process according to an embodiment of the disclosure.

FIG. 2 is an illustration of an exemplary flowchart showing a clearingprocess of the Fast-Flux malware detection process of FIG. 1 in moredetail according to an embodiment of the disclosure.

FIG. 3 is an illustration of an exemplary flowchart showing aSingle-Flux URL-IP changes detection process of the Fast-Flux malwaredetection process of FIG. 1 in more detail according to an embodiment ofthe disclosure.

FIG. 4 is an illustration of an exemplary flowchart showing aDouble-Flux authoritative DNS changes detection process of the Fast-Fluxmalware detection process of FIG. 1 in more detail according to anembodiment of the disclosure.

FIG. 5 is an illustration of an exemplary flowchart showing anidentifying overlap process of the Fast-Flux malware detection processof FIG. 1 in more detail according to an embodiment of the disclosure.

FIG. 6 is an illustration of an exemplary table showing possible rawstorage results for use with Fast Flux and Double Flux trackingaccording to an embodiment of the disclosure.

FIG. 7 is an illustration of an exemplary table showing data in asuspicious URLs storage according to an embodiment of the disclosure.

FIG. 8 is an illustration of an exemplary table showing data in asuspicious DNS domain storage according to an embodiment of thedisclosure.

FIG. 9 is an illustration of an exemplary functional block diagram of aFast-Flux malware detection system according to an embodiment of thedisclosure.

FIG. 10 is an illustration of an exemplary flowchart showing a Fast-Fluxmalware detection process according to an embodiment of the disclosure.

DETAILED DESCRIPTION

The following detailed description is exemplary in nature and is notintended to limit the disclosure or the application and uses of theembodiments of the disclosure. Descriptions of specific devices,techniques, and applications are provided only as examples.Modifications to the examples described herein will be readily apparentto those of ordinary skill in the art, and the general principlesdefined herein may be applied to other examples and applications withoutdeparting from the spirit and scope of the disclosure. The presentdisclosure should be accorded scope consistent with the claims, and notlimited to the examples described and shown herein.

Embodiments of the disclosure may be described herein in terms offunctional and/or logical block components and various processing steps.It should be appreciated that such block components may be realized byany number of hardware, software, and/or firmware components configuredto perform the specified functions. For the sake of brevity,conventional techniques and components related to signal processing,network and data communication, the Internet, Local Area Network (LAN),Wide Area Network (WAN), and other functional aspects of systemsdescribed herein (and the individual operating components of thesystems) may not be described in detail herein. In addition, thoseskilled in the art will appreciate that embodiments of the presentdisclosure may be practiced in conjunction with a variety of hardwareand software, and that the embodiments described herein are merelyexample embodiments of the disclosure.

Embodiments of the disclosure are described herein in the context ofsome non-limiting applications, namely, client. Embodiments of thedisclosure, however, are not limited to such applications, and thetechniques described herein may also be utilized in other applications.For example but without limitation, embodiments may be applicable tocloud services, cyber-security services, or other internetcommunication.

As would be apparent to one of ordinary skill in the art after readingthis description, the following are examples and embodiments of thedisclosure and are not limited to operating in accordance with theseexamples. Other embodiments may be utilized and structural changes maybe made without departing from the scope of the exemplary embodiments ofthe present disclosure.

The Domain Name System (DNS) is a standard technology for managing thenames of Web sites and other Internet domains. DNS technology allows auser to type names into the user Web browser like“compnetworking.about.com” and the user computer to automatically findthat address on the Internet. An important element of the DNS is aworldwide collection of DNS servers. A DNS server is any computerregistered to join the Domain Name System. A DNS server runsspecial-purpose networking software, features a public IP address, andcontains a database of network names and addresses for other Internethosts.

As mentioned above, attackers have over time evolved better techniquesfor performing call-backs so that it is more difficult to catch whereinfected hosts may be attempting to connect to. One of the most advancedcurrent techniques uses techniques referred to as “Fast-Flux” and maycomprise a “Single-Flux” and/or a “Double-Flux” network system foravoiding detections. Embodiments of the disclosure detect theseSingle-Flux and Double-Flux systems. These Flux networks work by usingDNS networks to resolve URL values to IP addresses. Infected hosts donot need to have IP addresses pre-programmed, instead the URL or URLlist remains static while the IP address that it resolves to can changeon a regular and sometimes rapid basis.

A simplest type of Fast Flux, named “Single-Flux”, is characterized bymultiple individual nodes within a network registering andde-registering their addresses as part of the DNS (address) record listfor a single DNS name. This combines round robin DNS with a short (e.g.,less than five minutes (300 s)) time-to-live (TTL) values to create aconstantly changing list of destination addresses for that single DNSname. The list can be hundreds or thousands of entries long. A timeframe that the TTL values will change may be difficult to determine, andisn't necessarily this short. A frequency of change may be significant.

A more sophisticated type of Fast-Flux, referred to as “Double-Flux”, ischaracterized by multiple nodes within the network registering andde-registering their addresses as part of the DNS Name Server recordlist for the DNS zone. This provides an additional layer of redundancyand survivability within a malware network.

Double-Flux systems resolve entire domains, and change the DNS serverresolution to further increase volatility of a communication line,allowing more servers to participate in a command and control structure.A complexity and robustness of this communication structure makes itextremely difficult for network administrators and security personnel toidentify infected devices which may be using this form of communication.Additionally, web and DNS traffic is often entirely overlooked bysecurity personnel due to the volume and frequency that it occurs.Embodiments of the disclosure, address a problem of not being able toidentify these infected devices by tracking URL-to-IP and DNSDomain-to-DNS server pairs and changes that they undergo, attempting toidentify a communication system (i.e., identification of suspect URLsand DNS domains) that an infection uses so that infected devices canthen be tracked and cleaned.

Identification of infected devices is currently performed using largelysignature-based detection and human-in-the-loop examination. A problemof communication through the use of Single-Flux (URL-IP) and Double-Flux(DNS Domain) networks is not addressed in existing systems. Firewallingand blocking of suspect IPs is done using standard firewalls, whereasblocking URLs and DNS can be performed using services such as WebSense™,however these services require one or more of: 1) A subscription to theWebSense™ service, which provides a list and groupings of various URLsand Domains, which then allow administrators to block or approveconnections based on specific URLs or URL groupings, and 2) Manual inputand tuning of a WebSense™ URL Filtering device, to add and/or removespecific URLs and domains. Additionally, tools such as WebSense™ (orother whitelist/blacklist URL filters) use a pre-defined URL name list.In contrast, Embodiments dynamically discover suspected URLsautomatically.

Moreover, existing systems do not effectively identify URLs thatfrequently change IP addresses or change authoritative DNS servers. Theexisting systems generally use pre-defined lists of known suspiciousURLs, IPs, or DNS Domains to perform detections. In contrast,embodiments of the disclosure use only algorithms to determinesuspicious behaviors which allows for previously unknowingly bad URLs,IPs, or DNS Domains to be identified. As mentioned above, embodimentsaddress a gap in current security monitoring and analysis systems andaims to identify Single-Flux and Double-Flux networks with the purposeof identifying internally infected network devices, which is a task thatis not being performed by any service today.

Furthermore, the existing systems rely on security personnel to discoversome anomaly prior to investigating beaconing attempts. Beaconingattempts are inherently difficult to find due to the amount of trafficdata seen on a corporate-size network. In contrast, embodiments of thedisclosure use automated algorithms to detect these suspicious URLs,IPs, and DNS Domains. Security personnel are difficult to train andemployees are a relatively high expense. Often security personnel areoverworked and don't have time to address non-critical issues, sofinding possibly infected hosts takes a back seat to more imminentnon-optimality. In this manner, embodiments of the disclosure provide ameans for security personnel to identify the infected devices withouthaving to spend time doing so themselves, reducing their overallworkload while allowing them to spend time more judiciously andincreasing security on a monitored network.

Additionally, the existing systems provide only ways to block access toproblematic IP addresses and URLs, but do not address finding thoseproblematic values. An existing technique requires subscriptions,licenses, and proprietary hardware, all which cost additional money, andwhich ultimately only provides a list of probable-cause values, withoutidentifying either the Single-Flux or Double-Flux networks, or locallyinfected devices. The locally infected devices therefore are not cleanedof the infection, even if they are placated by an inability tocommunicate (and assuming that other communication methods aren'talready in place as a command-and-control backup system).

As explained in more detail below, embodiments of the disclosure detectFast-Flux computer malware by examining and tracking URL-to-IPresolution requests as well as the authoritative DNS servers which areproviding the URL resolutions. By looking for changes in the pairingsURL-to-IP, and DNS Domain-to-DNS server embodiments identify the URLsand DNS servers most likely involved in a Fast-Flux malware network.Filters and control parameters are applied to the Fast-Flux detectionprocess to limit the number of false positive detections, and thedetected cases are used to identify network devices that may have beencompromised.

FIGS. 1-5 are illustrations of exemplary flowcharts showing Fast-Fluxmalware detection processes 100-500 according to an embodiment of thedisclosure. The various tasks performed in connection with the processes100-500 may be performed by software, hardware, firmware, acomputer-readable medium having computer executable instructions forperforming the process method, or any combination thereof. The processes100-500 may be recorded in a non-transitory computer-readable mediumsuch as a semiconductor memory, a magnetic disk, an optical disk, andthe like, and can be accessed and executed, for example, by a computerCPU such as the processor module 906 (FIG. 9) in which thecomputer-readable medium is stored.

It should be appreciated that the processes 100-500 may include anynumber of additional or alternative tasks, the tasks shown in FIGS. 1-5need not be performed in the illustrated order, and the processes100-500 may be incorporated into a more comprehensive procedure orprocess having additional functionality not described in detail herein.In some embodiments, portions of the processes 100-500 may be performedby different elements of a Fast-Flux detection system 900 (FIG. 9) suchas: a network traffic monitor 902, a malware detector 904, a processormodule 906, a memory module 908, a communication module 910, etc.Processes 100-500 may have functions, material, and structures that aresimilar to the embodiments shown in FIGS. 1-5. Therefore commonfeatures, functions, and elements may not be redundantly described here.

FIG. 1 is an illustration of an exemplary flowchart showing a Fast-Fluxmalware detection process 100 according to an embodiment of thedisclosure. Process 100 shows a high level Fast-Flux malware detectionprocess 100, its expected inputs and outputs and the high levelfunctionality of the Fast-Flux malware detection process 100.

Process 100 may begin by providing an input data such as the input data103 (task 102). The input data 103 to the process 100 may comprise DNSresolutions information sources 103A (DNS resolution information 103A),which have occurred though some means. This information comprises mostimportantly an association of a URL to a specific internet IP address(URL-to-IP) as well as associations of DNS Domains to authoritative DNSservers (DNS Domain-to-DNS server). The input data 103 may be obtained,for example but without limitation, by logging the DNS queries andresults 103B (DNS server logging 103B) from a localized DNS server(either on a local machine as in Local DNS resolutions 103C or adedicated server on a regional network), performing analysis of DNStraffic from packet captures 103D (DNS packet capture analysis 103D) orperforming automated, intentional DNS queries 103E (deliberate DNSresolution testing 103E) for URLs or domains which may be suspect, orother means of collecting the input.

Process 100 may continue by collecting the input data 103 from anyfeeder sources and run raw data through an initial filtering mechanism(task 104). Filtering is performed based on a DNS collection filteringconfiguration list 105 (filter 105) maintained manually orautomatically. The filter 105 is used to limit the input data 103 fromthe task 102 to be free from DNS resolution information that has alreadybeen investigated and determined not to be suspicious. If the incomingDNS resolution information 103A of the input data 103 is marked to befiltered out (Yes branch of inquiry task 104), then it is ignored (task106), otherwise (No branch of inquiry task 104), the input data 103 isnormalized (task 108) to provide normalized input data.

The normalization task 108 converts the input data 103 into a standardform to provide the normalized input data that can be stored in a DNSinformation storage database 110. Exemplary normalized input data areshown in table 600 (FIG. 6) below.

The normalized input data from the DNS information storage database 110is removed from the DNS information storage database 110 (task 124)usually on a time interval (e.g., all data arriving in the last 10minutes) and is processed in parallel by both a URL-to-IPchange-over-time detector (aka Single-Flux APT) (task 112) and anauthoritative DNS server change-over-time detector (aka Double-Flux APT)(task 114). Tasks 112 and 114 are shown below in more detail in thecontext of discussion of FIGS. 3 and 4 respectively.

Process 100 may continue by providing output data (task 116). The outputdata or event list may comprise, for example but without limitation,data in a form of security events that indicate that specific URLs,specific Domains, or both a specific URL and a specific Domain, aresuspected as being part of an APT botnet. A botnet is a collection ofinternet-connected programs communicating with other similar programs inorder to perform tasks.

Output data from the tasks 112 and 114 comprise both event lists andtracking data. The tracking data for suspicious URL is stored in asuspicious URL storage database 118 as shown in an exemplary table 700(FIG. 7) below. The tracking data for suspicious DNS domain is stored inan authoritative DNS storage database 120 as shown in an exemplary table800 (FIG. 8).

Process 100 may then continue by identifying overlapping findings (task122) from the Single-Flux detector (task 112) and the Double-Fluxdetector (task 114). The suspicious URL storage database 118 and theauthoritative DNS storage database 120 provide input to the task 122 toidentify overlapping findings from the Fast-Flux and Double-Fluxdetectors which then may output additional event list (task 116) items.

Process 100 may continue by database cleanup processes (tasks 124, 126and 128) as explained in more detail in the context of discussion ofFIG. 2 below. The database cleanup processes tasks 124, 126 and 128 keepthe data in their respective storages trimmed and storing onlyappropriate data.

FIG. 2 is an illustration of an exemplary flowchart showing a clearing(cleanup) process 200 of the Fast-Flux malware detection process 100 ofFIG. 1 in more detail according to an embodiment of the disclosure. Theclearing process 200 performs the tasks 124, 126, and 128 of thedetection process 100 to keep the data trimmed and stores onlyappropriate data in the three respective storage databases 110, 118, and120. The same process is used for each of the tasks 124, 126, 128.

All data is reviewed one element (row) at a time (202, 214, and 226).Each element (row) is checked to determine it is older than a time limit(inquiry tasks 204, 216, and 228). The time limit (210, 222, and 234)may be configured manually. For example but without limitation, anominal time limit may be configured to keep data no more than 12months, or other time limit. If the element is older than the time limit(Yes branch of inquiry tasks 204, 216, and 228) then that row is deleted(removed) from the storage (tasks 208, 220, and 232). If the element isnot older than the time limit (No branch of inquiry tasks 204, 216, and228) then it is further compared (inquiry tasks 206, 218, and 230) to alist of known non-suspicious URLs and non-suspicious domains and/ornon-suspicious authoritative DNS servers (212, 224, and 236). If thedata element (row) from the data storage contains information that isnow believed to be no longer suspicious (i.e., marked as now filtered,Yes branch of inquiry tasks 206, 218, and 230) then the data element(row) is deleted (removed) from the data store (tasks 208, 220, 232).

FIG. 3 is an illustration of an exemplary flowchart showing aSingle-Flux URL-IP changes detection process 300 of the Fast-Fluxmalware detection process 100 of FIG. 1 in more detail according to anembodiment of the disclosure.

Process 300 may begin by collecting a list (task 302) of all of the newURL-IP associations added to the DNS information storage database 110since the last time the processing was performed (or, in the case thatprocessing is continually being performed, the next newest result fromthe storage). For each result retrieved, a series of actions andanalysis is then performed based on the data provided by the result andthe historical data stored (from other results) in order to determinewhether a change in the IP address for the URL is suspicious (or not) asexplained below.

For each new result, data is passed in parallel to four differentprocesses: total quantity of URL-to-IP association changes (tasks306-312), quantity of URL-to-IP association changes in a time period(tasks 314-322), frequency of URL-to-IP association changes (tasks 326to 334), and patterns of URL-to-IP association changes (tasks 336 to342).

Each URL-to-IP mapping data element such as a row 602 in the table 600(FIG. 6) is checked at inquiry task 306 to determine if the totalquantity of changes detection should be performed for this URL and/orIP. This additional filtering step allows restrictions to be placed onresults for only this type of detection, not all detections. This filteris controlled from a filter list 304 that may be manually controlled. Ifthis result is filtered out (Yes branch of inquiry task 306) then it isignored (task 324) and process 300 continues with the next new item (newURL-TO-IP-mapping) (task 302). If the result is not filtered out (Nobranch of inquiry task 306) then an entire storage history from the DNSinformation storage database 110 is searched for other occurrences wherethe URL is a match, and a number of results returned are countedcounting a total number of association changes (total number of URL-IPMapping changes) (task 308) and compared to a configuredtotal-association-change-threshold (inquiry task 310) for this type ofdetection.

The total-association-change-threshold configuration (312) is suitablyset for operation of the system 900. For example but without limitation,total-association-change-threshold may be 500 changes (e.g., where thetotal stored timeframe is 12 months). Total changes may be looselydependent on a total timeframe for data stored. If the number of results(number of total changes) (task 308) is greater than thetotal-association-change-threshold (Yes branch of inquiry task 310), theprocess 300 proceeds to task 346 and logs suspicious URL data to providea suspicious resource log.

Each URL-to-IP mapping data element such as the row 602 in table 600 ischecked at inquiry task 314 to determine if the quantity of changeswithin a time period detection should be performed for this URL and/orIP. This additional filtering step allows restrictions to be placed onresults for only this type of detection, not all detections. This filteris controlled from a filter list 316 that may be manually controlled. Ifthis result is filtered out (Yes branch of inquiry task 314), then it isignored (task 324) and process 300 continues with the next new item(task 302). If the result is not filtered out (No branch of inquiry task314), then the entire storage history from the DNS information storagedatabase 110 is searched for other occurrences where the URL is a match,and the number of results returned are counted, counting a number ofassociation changes in a time-period (task 318) and compared to aconfigured time-period-association-changes-threshold (inquiry task 320)for this type of detection.

The time-period-association-changes-threshold (322) is suitably set foroperation of the system 900. For example but without limitation, thetime-period-association-changes-threshold may be 50 changes for a 1 hourtime period. The threshold is a single value against which a number ofchanges is compared. If the number of results (task 318) is greater thanthe time-period-association-changes-threshold (Yes branch of inquirytask 320), the process 300 proceeds to task 346.

Each URL-to-IP mapping data element such as the row 602 in the table 600is checked at inquiry task 326 to determine if the frequency of changesdetection should be performed for this URL and/or IP. This additionalfiltering step allows restrictions to be placed on results for only thistype of detection, not all detections. This filter is controlled from afilter list 328 that may be manually controlled. If this result isfiltered out (Yes branch of inquiry task 326) then it is ignored (task352) and process 300 continues with the next new item (task 302). If theresult is not filtered out (No branch of inquiry task 326) then theentire storage history is searched for other occurrences where the URLis a match, and the frequency of changes of the URL-to-IP mapping iscalculated calculating an association change frequency (task 330) andcompared to a configured association-change-frequency-threshold (inquirytask 332) for this type of detection.

The association-change-frequency-threshold 334 is suitably set foroperation of the system 900. For example, but without limitation, theassociation-change-frequency-threshold may be 5 minutes, indicating thata change of the URL-to-IP mapping occurs usually more frequently thanonce every 5 minutes. This change frequency may be represented in adifferent manner, but the association-change-frequency-threshold 334 mayindicate a limit on how often the change occurs, and results pass theassociation-change-frequency-threshold 334 if the change of theURL-to-IP mapping occurs more often than theassociation-change-frequency-threshold 334 specifies. If the frequencyof changes of the URL-to-IP mapping (task 330) is less than theassociation-change-frequency-threshold 334 (Yes branch of inquiry task332), the process 300 proceeds to task 346.

Each URL-to-IP mapping data element such as the row 602 in table 600 ischecked at inquiry task 336 to determine if the patterns of changes ofURL-to-IP association detection should be performed for this URL and/orIP. This additional filtering step allows restrictions to be placed onresults for only this type of detection, not all detections. This filteris controlled from a filter list 338 that may be manually controlled. Ifthis result is filtered out (Yes branch of inquiry task 336) then it isignored (task 338) and process 300 continues with the next new item(task 302). If the result is not filtered out (No branch of inquiry task336) then the entire storage history from the DNS information storagedatabase 110 is searched for any items that match the URL (task 340).The found items are organized chronologically and examined to determineif a pattern, or patterns, is present (inquiry task 342).

A pattern configuration 344 is suitably set for operation of the system900. For example, but without limitation, the pattern configurations 344may be a consistent amount of time between changes in the URL-IPresolution, or other pattern. If the pattern, or patterns, are present(Yes branch of inquiry task 342), the process 300 proceeds to task 346.

For each result path reaching process 300 logs suspicious URL data (task346) in suspicious resource log, stores suspicious URL in the suspiciousURL storage 354 (task 348) for later use. Then process 300 searches theentire DNS information storage database 110 and retrieves a list of allclient devices that have queried this suspicious URL within a timeperiod (task 350). This provides information if there were more than oneinfected client device that is performing the same suspicious access.This data is then provided to an event generation process (task 352)which will consolidate detected suspicious URLs so that there are notunnecessary duplicate events generated to the external event list (task116).

FIG. 4 is an illustration of an exemplary flowchart showing aDouble-Flux authoritative DNS changes detection process 400 of theFast-Flux malware detection process of FIG. 1 in more detail accordingto an embodiment of the disclosure. Process 400 may have functions,material, and structures that are similar to the embodiments shown inprocess 300. Therefore common features, functions, and elements may notbe redundantly described here. The principal difference between process300 and 400 is that the process 400 is performed using an associationbetween a Domain and an authoritative DNS server location address (suchas IP).

Instead of the URLs, process 400 uses Domains, and instead of device IPaddresses corresponding to the URLs, a location address of theauthoritative DNS server is used. The process 400 uses data similar toprocess 300 such as input and output events as well as insertinginformation about suspicious domains into a storage database. So process400 is not redundantly described herein.

For example, process 400 configures a resource association listcomprising the DNS Domain-to-DNS server associations list instead ofURL-to-IP associations list configured by the process 300. Process 400configures a suspicious DNS log instead of a suspicious URL logconfigured by the process 300.

FIG. 5 is an illustration of an exemplary flowchart showing the overlapidentifying process 500/122 of the Fast-Flux detection process of FIG. 1in more detail according to an embodiment of the disclosure. The process122 identifies Single-Flux URL and Double-Flux authoritative DNS serverdomain overlap. The process 122 uses the suspicious URL storage 354outputted in the process 300 and the suspicious authoritative DNSstorage 454 outputted in the process 400 as input and produces the eventlist 116 for use by the external systems.

The process 122 may begin by gathering a list of new (unprocessed) itemsfrom the suspicious URL storage 354 (task 502) and from the suspiciousauthoritative DNS storage 454 (task 512) and iterating through eachitem.

For each suspicious URL items from the task 502 a search is performed inthe suspicious authoritative DNS storage 454 for Double-Flux resultswhich occurred during the same time period that the URL was consideredsuspicious (task 504). Finding both at the same time indicates that boththe URL and the domain underwent changes during the same period of time,indicating that both single-Flux and Double-Flux actions were active. Ifa match is not found (No branch of inquiry task 506) then this elementis ignored (task 508) and process 122 continues processing with the nextelement. If a match is found (Yes branch of inquiry task 506) thencombine all known data and generate an event for combination found (task510) to be output to an external event list (task 116).

For the suspicious domain items from task 512 a search is performed inthe suspicious URL storage 354 for Single-Flux results which occurredduring the same time period that the domain was considered suspicious(task 514). Finding both at the same time indicates that both the domainand URL underwent address changes during the same period of time,indicating that both Double Flux and Single Flux actions were active. Ifa match is not found (No branch of inquiry task 516) then this elementis ignored (task 508) and process 122 continues with the next element.If a match is found (Yes branch of inquiry task 516) then process 122combine all known data and generate an event for the combination found(task 518) to be output to the external event list (task 116).

FIG. 6 is an illustration of an exemplary table 600 showing possible rawstorage results for use with Single-Flux and Double-Flux trackingaccording to an embodiment of the disclosure. The table 600 shows anexample of a possible storage solution for storing the DNS data in DNSinformation storage database 110. Row 602 shows exemplary normalizedrecords stored in the DNS information storage database 110. Otherdatabase formats and data suitable for operation of system 900 may alsobe used to generate the table 600.

FIG. 7 is an illustration of an exemplary table 700 showing data in asuspicious URLs storage according to an embodiment of the disclosure.The table 700 provides an example of a possible storage solution for thelist of suspicious URL storage database 118 and 354. Other databaseformats and data suitable for operation of system 900 may also be usedto generate the table 700.

FIG. 8 is an illustration of an exemplary table showing data in asuspicious DNS domain storage according to an embodiment of thedisclosure. The table 800 shows an example of a possible storagesolution for the list of the tracking data for suspicious DNS domainsstored in the authoritative DNS storage database 120 and 448. Otherdatabase formats and data suitable for operation of system 900 may alsobe used to generate the table 800.

FIG. 9 is an illustration of an exemplary functional block diagram of aFast-Flux detection system 900 according to an embodiment of thedisclosure. The Fast-Flux detection system 900 may comprise: a networktraffic monitor 902, a malware detector 904, a processor module 906, amemory module 908, and a communication module 910.

The network traffic monitor 902 is configured to monitor a plurality ofdomain name system (DNS) lookup requests 914 to one or more DNS servers916 from a local area network (LAN) 918 to a wide area network (WAN)920, the DNS lookup requests 914 comprising a plurality of requests toresolve one or more uniform resource locators (URLs) to one or morereceived network addresses (e.g., internet protocol (IP) addresses). Thenetwork traffic monitor 902 is further configured to monitor thereceived network addresses (IP) 922 received for the URLs 924 from theDNS servers 916 for the DNS lookup requests 914 to provide a URL-to-IPassociations list 928. The received network addresses (IP) 922 maycomprise, for example but without limitation, an internet protocoladdress, an Ethernet address, or other network address. The networktraffic monitor 902 is further configured to monitor the DNS servers 916used for the DNS lookup requests 914 for the URLs 924 to provide a DNSDomain-to-DNS server associations list 926.

The malware detector 904 is configured to generate the suspicious URLlog 346 based on the URL-to-IP associations list 928 and the suspiciousDNS log 446 based on the DNS Domain-to-DNS server associations list 926and indicate a presence of a malware program in the LAN 918 based on thesuspicious URL log 346 and the suspicious DNS log 446.

The processor module 906 comprises processing logic that is configuredto carry out the functions, techniques, and processing tasks associatedwith the operation of the system 900. In particular, the processinglogic is configured to support the system 900 described herein. Forexample, the processor module 906 may direct the network traffic monitor902 and the malware detector 904 in the system 900.

The processor module 906 may be implemented, or realized, with a generalpurpose processor, a content addressable memory, a digital signalprocessor, an application specific integrated circuit, a fieldprogrammable gate array, any suitable programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof, designed to perform the functions described herein.In this manner, a processor may be realized as a microprocessor, acontroller, a microcontroller, a state machine, or the like. A processormay also be implemented as a combination of computing devices, e.g., acombination of a digital signal processor and a microprocessor, aplurality of microprocessors, one or more microprocessors in conjunctionwith a digital signal processor core, or any other such configuration.

The memory module 908 may comprise a data storage area with memoryformatted to support the operation of the system 900. The memory module908 is configured to store, maintain, and provide data as needed tosupport the functionality of the system 900. For example but withoutlimitation, the memory module 908 may store data, such as but withoutlimitation, the network address 922, the suspicious URL storage database118, the suspicious DNS domain storage database 120/454, the suspiciousURL log 346, the suspicious DNS log 446, the URL-to-IP list 928, theDNS-To-DNS server association list 926, time, date, frequency, pattern,or other data.

In some embodiments, the memory module 908 may comprise, for example butwithout limitation, a non-volatile storage device (e.g., non-volatilesemiconductor memory, hard disk device, optical disk device, and thelike), a random access storage device (for example, SRAM, DRAM), or anyother form of non-transitory storage medium known in the art.

Additionally, the memory module 908 may represent dynamically updatingdatabases containing tables for updating the databases, and the like.The memory module 908 may also store, a computer program that isexecuted by the processor module 906, an operating system, anapplication program, tentative data used in executing a program, orother application.

The memory module 908 may be coupled to the processor module 906 suchthat the processor module 906 can read information from and writeinformation to the memory module 908. For example, the processor module906 may access the memory module 908 to access the data stored in thememory module 908 as explained above.

As an example, the processor module 906 and memory module 908 may residein respective application specific integrated circuits (ASICs). Thememory module 908 may also be integrated into the processor module 906.In an embodiment, the memory module 908 may comprise a cache memory forstoring temporary variables or other intermediate information duringexecution of instructions to be executed by the processor module 906.

The communication module 910 is operable to transmit and receive aplurality of communication signals comprising data signals via atransceiver (not shown) under control of the processor module 906. Thecommunication module 910 operates with an antenna 912 to carry out aradio communication with a network side device via a base stationcommunicatively coupled to a wireless communication network (not shown).

The communication module 910 can transmit a signal from the processormodule 906 as a transmitted radio signal to a base station through theantenna 912, and can demodulate a received radio signal received fromthe base station through the antenna 912. The processor module 906receives a demodulated signal form the communication module 910.

The communication module 910 may also comprise an Ethernet/USBcommunication module (not shown) configured to provide communicationbetween the system 900 and the electronic resources via Ethernet. TheEthernet/USB communication module communicates with the Internet throughan access port to download documents, and to interact with Web-basedservices.

Those skilled in the art will understand that the various illustrativeblocks, modules, circuits, and processing logic described in connectionwith the embodiments disclosed herein may be implemented in hardware,computer-readable software, firmware, or other combination thereof. Toclearly illustrate this interchangeability and compatibility ofhardware, firmware, and software, various illustrative components,blocks, modules, circuits, and steps are described generally in terms oftheir functionality.

In some embodiments, the system 900 may comprise any number of processormodules, any number processing modules, any number of memory modules,any number of transmitter modules, and any number of receiver modulessuitable for their operation described herein. The illustrated system900 depicts a simple embodiment for ease of description. These and otherelements of the system 900 are interconnected together, allowingcommunication between the various elements of system 900. In oneembodiment, these and other elements of the system 900 may beinterconnected together via a respective data communication bus 926.

A transmitter module and a receiver module may be located in theprocessor module 906 coupled to a shared antenna 912. Although in asimple module only one shared antenna 912 may be provided, moresophisticated modules may be provided with multiple and/or more complexantenna configurations. Additionally, although not shown in this FIG. 9,those skilled in the art will recognize that a transmitter may transmitto more than one receiver, and that multiple transmitters may transmitto a same receiver.

Whether such functionality is implemented as hardware, firmware, orsoftware depends upon the particular application and design constraintsimposed on the overall system. Those familiar with the conceptsdescribed herein may implement such functionality in a suitable mannerfor each particular application, but such implementation decisionsshould not be interpreted as causing a departure from the scope of thepresent invention.

FIG. 10 is an illustration of an exemplary flowchart showing a Fast-Fluxmalware detection process (process 1000) according to an embodiment ofthe disclosure. The various tasks performed in connection with process1000 may be performed mechanically, by software, hardware, firmware,computer-readable software, computer readable storage medium, or anycombination thereof. It should be appreciated that process 1000 mayinclude any number of additional or alternative tasks, the tasks shownin FIG. 10 need not be performed in the illustrated order, and theprocess 1000 may be incorporated into a more comprehensive procedure orprocess having additional functionality not described in detail herein.

For illustrative purposes, the following description of process 1000 mayrefer to elements mentioned above in connection with FIG. 9. In someembodiments, portions of the process 1000 may be performed by differentelements of the system 900 such as: the network traffic monitor 902, themalware detector 904, the processor module 906, the memory module 908,the communication module 910, etc. It should be appreciated that process1000 may include any number of additional or alternative tasks, thetasks shown in FIG. 2 need not be performed in the illustrated order,and the process 1000 may be incorporated into a more comprehensiveprocedure or process having additional functionality not described indetail herein.

Process 1000 may begin by monitoring a plurality of domain name system(DNS) lookup requests to one or more DNS servers from a local areanetwork (LAN) to a wide area network (WAN), the DNS lookup requestscomprising a plurality of requests to resolve one or more uniformresource locators (URLs) to one or more received network addresses (IP)(task 1002).

Process 1000 may continue by monitoring the received network addresses(IP) received for the URLs from the DNS servers for the DNS lookuprequests to provide a URL-to-IP associations list (task 1004).

Process 1000 may continue by monitoring the DNS servers used for the DNSlookup requests for the URLs to provide a DNS Domain-to-DNS serverassociations list (task 1006).

Process 1000 may continue by generating a suspicious URL log based onthe URL-to-IP associations list and a suspicious DNS log based on theDNS Domain-to-DNS server associations list (task 1008).

Process 1000 may continue by indicating a presence of a malware programin the LAN based on the suspicious DNS log and the suspicious URL log(task 1010).

Process 1000 may continue by configuring a resource association listcomprising the URL-to-IP associations list or the DNS Domain-to-DNSserver associations list (task 1012).

Process 1000 may continue by configuring a suspicious resource logcomprising the suspicious URL log or the suspicious DNS log (task 1014).

Process 1000 may continue by counting a total number of associationchanges in the resource association list (task 1016).

Process 1000 may continue by logging the suspicious resource log, if thetotal number of association changes is greater than atotal-association-change threshold (task 1018).

Process 1000 may continue by counting a number of association changes inthe resource association list in a time-period (task 1020).

Process 1000 may continue by logging the suspicious resource log, if thenumber of association changes in the time-period is greater than atime-period-association-changes threshold (task 1022).

Process 1000 may continue by calculating an association change frequencyof the resource association list (task 1024).

Process 1000 may continue by logging the suspicious resource log, if theassociation change frequency is greater than anassociation-change-frequency threshold (task 1026).

Process 1000 may continue by calculating a pattern in the resourceassociation list (task 1028).

Process 1000 may continue by logging the suspicious resource log, if thepattern is found among a pattern history (task 1030).

In this manner, a system and method are provided to identify Single-Fluxand Double-Flux networks with the purpose of identifying internallyinfected network devices, which is a task that is not being performed byexisting systems. Embodiments of the disclosure detect APT computermalware by examining and tracking URL-to-IP resolution requests as wellas the authoritative DNS servers which are providing the URLresolutions. By searching for changes in the pairings, embodimentsidentify the URLs and DNS servers most likely involved in a Fast-Fluxmalware network.

Terms and phrases used in this document, and variations thereof, unlessotherwise expressly stated, should be construed as open ended as opposedto limiting. As examples of the foregoing: the term “including” shouldbe read as meaning “including, without limitation” or the like; the term“example” is used to provide exemplary instances of the item indiscussion, not an exhaustive or limiting list thereof; and adjectivessuch as “conventional,” “traditional,” “normal,” “standard,” “known” andterms of similar meaning should not be construed as limiting the itemdescribed to a given time period or to an item available as of a giventime, but instead should be read to encompass conventional, traditional,normal, or standard technologies that may be available or known now orat any time in the future.

Likewise, a group of items linked with the conjunction “and” should notbe read as requiring that each and every one of those items be presentin the grouping, but rather should be read as “and/or” unless expresslystated otherwise. Similarly, a group of items linked with theconjunction “or” should not be read as requiring mutual exclusivityamong that group, but rather should also be read as “and/or” unlessexpressly stated otherwise. Furthermore, although items, elements orcomponents of the disclosure may be described or claimed in thesingular, the plural is contemplated to be within the scope thereofunless limitation to the singular is explicitly stated. The presence ofbroadening words and phrases such as “one or more,” “at least,” “but notlimited to” or other like phrases in some instances shall not be read tomean that the narrower case is intended or required in instances wheresuch broadening phrases may be absent.

The above description refers to elements or nodes or features being“connected” or “coupled” together. As used herein, unless expresslystated otherwise, “connected” means that one element/node/feature isdirectly joined to (or directly communicates with) anotherelement/node/feature, and not necessarily mechanically. Likewise, unlessexpressly stated otherwise, “coupled” means that oneelement/node/feature is directly or indirectly joined to (or directly orindirectly communicates with) another element/node/feature, and notnecessarily mechanically. Thus, although FIG. 9 depicts examplearrangements of elements, additional intervening elements, devices,features, or components may be present in an embodiment of thedisclosure.

In this document, the terms “computer program product”,“computer-readable medium”, “computer readable storage medium”, and thelike may be used generally to refer to media such as, for example,memory, storage devices, or storage unit. These and other forms ofcomputer-readable media may be involved in storing one or moreinstructions for use by the processor module 906 to cause the processormodule 906 to perform specified operations. Such instructions, generallyreferred to as “computer program code” or “program code” (which may begrouped in the form of computer programs or other groupings), whenexecuted, enable the system 900.

As used herein, unless expressly stated otherwise, “operable” means ableto be used, fit or ready for use or service, usable for a specificpurpose, and capable of performing a recited or desired functiondescribed herein. In relation to systems and devices, the term“operable” means the system and/or the device is fully functional andcalibrated, comprises elements for, and meets applicable operabilityrequirements to perform a recited function when activated. In relationto systems and circuits, the term “operable” means the system and/or thecircuit is fully functional and calibrated, comprises logic for, andmeets applicable operability requirements to perform a recited functionwhen activated.

The invention claimed is:
 1. A method for detecting Fast-Flux malware,the method comprising: monitoring by a network traffic monitor aplurality of domain name system (DNS) lookup requests to one or more DNSservers initiated by one or more network devices in a local area network(LAN) to a wide area network (WAN), the DNS lookup requests comprising aplurality of requests to resolve one or more uniform resource locators(URLs) to one or more received network addresses (IP); monitoring theone or more received network addresses (IP) resolved for the one or moreURLs to provide a URL-to-IP associations list, wherein the URL-to-IPassociations list is configured to store one or more suspicious URLs;monitoring the one or more DNS servers used for the DNS lookup requestsfor resolving the URLs to provide a DNS Domain-to-DNS serverassociations list; generating a suspicious URL log based on theURL-to-IP associations list and a suspicious DNS log based on the DNSDomain-to-DNS server associations list; determining whether a designatedsuspicious URL from the suspicious URL log matches designated data inthe suspicious DNS log; and after determining that the designatedsuspicious URL from the suspicious URL log matches the designated datain the suspicious DNS log, generating an event indicating a combinationof flux actions are active.
 2. The method of claim 1, further comprisingindicating a presence of a malware program in the LAN based on thesuspicious DNS log and the suspicious URL log.
 3. The method of claim 1,further comprising: configuring a resource association list comprisingthe URL-to-IP associations list or the DNS Domain-to-DNS serverassociations list; and configuring a suspicious resource log comprisingthe suspicious URL log or the suspicious DNS log.
 4. The method of claim3, further comprising: counting a total number of association changes inthe resource association list; and logging the suspicious resource log,if the total number of association changes is greater than atotal-association-change threshold.
 5. The method of claim 3, furthercomprising: counting a number of association changes in the resourceassociation list in a time-period; and logging the suspicious resourcelog, if the number of association changes in the time-period is greaterthan a time-period-association-changes threshold.
 6. The method of claim3, further comprising: calculating an association change frequency ofthe resource association list; and logging the suspicious resource log,if the association change frequency is greater than anassociation-change-frequency threshold.
 7. The method of claim 3,further comprising: calculating a pattern in the resource associationlist; and logging the suspicious resource log, if the pattern is foundamong a pattern history.
 8. A system for detecting Fast-Flux malware,the system comprising: at least one hardware processor; and a networktraffic monitor operating on the at least one hardware processor andconfigured to: monitor a plurality of domain name system (DNS) lookuprequests to one or more DNS servers initiated by one or more networkdevices in a local area network (LAN) to a wide area network (WAN), theDNS lookup requests comprising a plurality of requests to resolve one ormore uniform resource locators (URLs) to one or more received networkaddresses (IP); monitor the one or more received network addresses (IP)resolved for resolving the one or more URLs to provide a URL-to-IPassociations list; monitor the one or more DNS servers used for the DNSlookup requests for resolving the URLs to provide a DNS Domain-to-DNSserver associations list; and a malware detector configured to: generatea suspicious URL log based on the URL-to-IP associations list and asuspicious DNS log based on the DNS Domain-to-DNS server associationslist; determine whether a designated suspicious URL from the suspiciousURL log matches designated data in the suspicious DNS log; afterdetermining that the designated suspicious URL from the suspicious URLlog matches the designated data in the suspicious DNS log, generate anevent indicating a combination of flux actions are active; and indicatea presence of a malware program in the LAN based on the suspicious URLlog and the suspicious DNS log.
 9. The system of claim 8, wherein: aresource association list comprises the URL-to-IP associations list orthe DNS Domain-to-DNS server associations list; and a suspiciousresource log comprises the suspicious URL log or the suspicious DNS log.10. The system of claim 9, wherein the malware detector is furtherconfigured to: count a total number of association changes in theresource association list; and log the suspicious resource log, if thetotal number of association changes is greater than atotal-association-change threshold.
 11. The system of claim 9, whereinthe malware detector is further configured to: count a number ofassociation changes in the resource association list in a time-period;and log the suspicious resource log, if the number of associationchanges in the time-period is greater than atime-period-association-changes threshold.
 12. The system of claim 9,wherein the malware detector is further configured to: calculate anassociation change frequency of the resource association list; and logthe suspicious resource log, if the association change frequency isgreater than an association-change-frequency threshold.
 13. The systemof claim 9, wherein the malware detector is further configured to:calculate a pattern in the resource association list; and log thesuspicious resource log, if the pattern is found among a patternhistory.
 14. A non-transitory computer readable storage mediumcomprising computer-executable instructions for detecting Fast-Fluxmalware, the computer-executable instructions comprising: monitoring bya network traffic monitor a plurality of domain name system (DNS) lookuprequests to one or more DNS servers initiated by one or more networkdevices in a local area network (LAN) to a wide area network (WAN), theDNS lookup requests comprising a plurality of requests to resolve one ormore uniform resource locators (URLs) to one or more received networkaddresses (IP); monitoring the one or more received network addresses(IP) resolved for resolving the one or more URLs to provide a URL-to-IPassociations list; monitoring the one or more DNS servers used for theDNS lookup requests for resolving the URLs to provide a DNSDomain-to-DNS server associations list; generate a suspicious URL logbased on the URL-to-IP associations list and a suspicious DNS log basedon the DNS Domain-to-DNS server associations list; determining whether adesignated suspicious URL from the URL-to-IP associations list matchesdesignated data in the DNS Domain-to-DNS server associations list; andafter determining that the designated suspicious URL from the URL-to-IPassociations list matches the designated data in the DNS Domain-to-DNSserver associations list, generating an event indicating a combinationof flux actions are active.
 15. The non-transitory computer readablestorage medium of claim 14, further comprising computer-executableinstructions comprising: indicating a presence of a malware program inthe LAN based on the suspicious DNS log or the suspicious URL log. 16.The non-transitory computer readable storage medium of claim 14, furthercomprising computer-executable instructions comprising: configuring aresource association list comprising the URL-to-IP associations list orthe DNS Domain-to-DNS server associations list; and configuring asuspicious resource log comprising the suspicious URL log or thesuspicious DNS log.
 17. The non-transitory computer readable storagemedium of claim 16, further comprising computer-executable instructionscomprising: counting a total number of association changes in theresource association list; and logging the suspicious resource log, ifthe total number of association changes is greater than atotal-association-change threshold.
 18. The non-transitory computerreadable storage medium of claim 16, further comprisingcomputer-executable instructions comprising: counting a number ofassociation changes in the resource association list in a time-period;and logging the suspicious resource log, if the number of associationchanges in the time-period is greater than atime-period-association-changes threshold.
 19. The non-transitorycomputer readable storage medium of claim 16, further comprisingcomputer-executable instructions comprising: calculating an associationchange frequency of the resource association list; and logging thesuspicious resource log, if the association change frequency is greaterthan an association-change-frequency threshold.
 20. The non-transitorycomputer readable storage medium of claim 16, further comprisingcomputer-executable instructions comprising: calculating a pattern inthe resource association list; and logging the suspicious resource log,if the pattern is found among a pattern history.